Недавно Duncan Epping опубликовал интересную статью о параметре Mem.MinFreePct, который есть в настройках сервера VMware ESXi из состава vSphere. По-сути, этот параметр определяет, какое количество оперативной памяти VMkernel должен держать свободным на хосте, чтобы всегда были доступные ресурсы под нужды системы, и хост не вывалился в PSOD.

В VMware vSphere 4.1 параметр Mem.MinFreePct составлял 6% и его можно было изменять с помощью следующей команды:

vsish -e set /sched/freeMemoryState/minFreePct <Percentage>

Например, вот так можно было установить Mem.MinFreePct в значение 2%:

vsish -e set /sched/freeMemoryState/minFreePct 2

Этак команда, кстати, не требует перезагрузки, но зато после перезагрузки значение Mem.MinFreePct не сохраняется. Поэтому данную команду, если требуется, нужно занести в /etc/rc.local (подробнее в KB 1033687).

Параметр этот очень важный, поскольку от него зависят пороги использования различных механизмов оптимизации памяти хоста ESXi. При этом, если памяти на хосте много (например, десятки гигабайт), то держать постоянно 6% свободной памяти может быть для кого-то расточительством. Поэтому, начиная с VMware vSphere 5.0, параметр Mem.MinFreePct является "плавающим" и устанавливается в зависимости от объема физической памяти на хосте ESXi.

Вот какие значения принимает Mem.MinFreePct в зависимости от того, сколько RAM есть на вашем физическом хост-сервере:

А вот какие механизмы оптимизации памяти на хосте работают, если свободной памяти становится все меньше и меньше:

Интересно, конечно, но как-то бесполезно. Зачем загонять хост в такие лимиты? Лучше как минимум процентов 10 всегда держать свободными и своевременно покупать новые серверы.

В прошлом посте мы писали о том, что компания StarWind сделала зомби-анонс восьмой версии своего решения для создания отказоустойчивых хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V.

В этом посте мы приведем еще немного забавных картинок и основные посылы восьмой версии продукта.

Во-первых, файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего):

Во-вторых, виртуальная среда рождает эффект IO-блендера, когда к системе хранения идут случайные чтения от большого числа ВМ, что создает существенные задержки. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что существенно увеличивает производительность:

Ну и, в-третьих, inline-дедупликация StarWind не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища:

Скоро появится больше информации. А пока приглашаем на промо-страницу StarWind V8.

Компания VMware опубликовала очередной номер своего технического журнала VMware Technical Journal Summer 2013, в котором разбираются наиболее интересные технические аспекты решений для виртуализации на весьма глубоком уровне (зачастую даже с математическими выкладками). Напомним, что о предыдущем выпуске VMware Technical Journal мы писали вот тут. Как и в прошлом выпуске все статьи доступны онлайн и как PDF (5 МБ).

Темы нового номера:

• Introduction
• Memory Overcommitment in the ESX Server
• Redefining ESXi IO Multipathing in the Flash Era
• Methodology for Performance Analysis of VMware vSphere under Tier-1 Applications
• vATM: VMware vSphere Adaptive Task Management
• An Anomaly Event Correlation Engine: Identifying Root Causes, Bottlenecks, and Black Swans in IT Environments
• Simplifying Virtualization Management with Graph Databases
• Autonomous Resource Sharing for Multi-Threaded Workloads in Virtualized Servers

Мне понравились "Redefining ESXi IO Multipathing in the Flash Era" и "Methodology for Performance Analysis of VMware vSphere under Tier-1 Applications".

На днях компания VMware объявила о начале публичного бета-тестирования своего нового средства для анализа логов VMware vSphere - VMware vCenter Log Insight 1.0. Продукт поставляется в виде виртуального модуля (Virtual Appliance), который развертывается как обычный OVF-пакет, после чего становится доступен сбор и анализ данных syslog с серверов VMware ESXi 4.1, 5.0, 5.1, а также vCenter Server Appliance и других источников. Кроме того, Log Insight может быть интегрирован с vCenter Operations Manager.

Возможности VMware vCenter Log Insight 1.0:

• High Performance Ingestion - Log Insight принимает данные от syslog или через API на скорости до 1000 Мбит/с на один виртуальный модуль
• Near Real-Time Search - входящие данные доступны для поиска почти сразу и могут быть агрегированы с историческими данными в одном большом логе.
• Aggregation - данные группируются методом похожим на GROUP-BY в реляционных БД.
• Runtime Field Extraction - Log Insight может доставать данные из сырого лога средствами регулярных выражений.
• Dashboards - администраторы могут создавать свои дэшборды из запросов к базе логов.
• Scalability - инфраструктуру Log Insight можно наращивать за счет добавления дополнительных серверов.

Полезная документация по продукту:

• VMware vCenter Log Insight 1.0 Beta Getting Started Guide
• VMware vCenter Log Insight 1.0 Beta Virtual Appliance Sizing
• Log Insight 1.0 Beta Installation and Administration Guide
• Log Insight 1.0 Beta User's Guide

Скачать бета-версию VMware vCenter Log Insight 1.0 можно по этой ссылке.

Когда-то давно мы публиковали заметки о P2V-миграции физических серверов в виртуальные машины на платформе тогда еще VMware ESX Server (а также рассказывали о необходимых действиях после миграции). С тех пор многое изменилось, вышел VMware vCenter Converter Standalone 5.0, процесс миграции стал проще и стабильнее, а также накопилось пару моментов, о которых можно рассказать. Кроме того, появилась отличная статья на эту тему. Итак, есть 3 типа P2V-миграции...

Многие знают, что VMware vSphere версий 5.0 (начиная с Update 1) и 5.1 в полном объеме поддерживают Windows Server 2012 и Windows 8 в гостевых ОС виртуальных машин. Однако, еще далеко не во всех компаниях установлены последние версии гипервизора VMware ESXi - особенно в крупных организациях еще много где используют версию ESX/ESXi 4.x.

При попытке установить Windows Server 2012 и Windows 8 в виртуальной машине ESX/ESXi 4.x, выбрав в качестве гостевой ОС Microsoft Windows Server 2008 R2, администратор получит вот такую ошибку:

Your PC ran into a problem that it couldn't handle, and now it needs to restart

You can search for the error online: HAL_INITIALIZATION_FAILED

Решить эту проблему очень просто:

• Создаем новую ВМ в vSphere Client.
• В качестве типа гостевой ОС (Guest Operating System) выбираем Microsoft Windows Server 2008 R2 (64-bit).
• Скачиваем вот этот файл bios и кладем его в папку с виртуальной машиной

Далее в конфигурационный файл .vmx в папке с ВМ добавляем следующие строчки:

bios440.filename = "bios.440.rom"
mce.enable = TRUE
cpuid.hypervisor.v0 = FALSE
vmGenCounter.enable = FALSE

Теперь можно устанавливать и использовать Windows 8 и Windows Server 2012 в виртуальной машине на VMware ESXi 4.1.

Второй этап - это установка свежих VMware Tools в таких виртуальных машинах. Об этом мы писали в статье "Как обновить VMware Tools старых хост-серверов, не обновляя хостов VMware vSphere / ESXi".

Те из вас, кто испытывает потребность в балансировке соединений в виртуальной инфраструктуре VMware vSphere, а также функциях безопасности, могут обратить свое внимание на продукт от Loadbalancer.org, поставляемый в виде виртуального модуля (Virtual Appliance).

Основные возможности продукта:

• Средства высокой доступности компонентов
• Полнофункциональная балансировка на уровнях 4/7
• Поддержка виртуальных и физических серверов
• Веб-консоль управления
• Функции HTTP Cookie Persistence
• Функции RDP Cookie Persistence
• Поддержка SSL Offloading
• Поддержка 802.1q VLAN
• Группировка интерфейсов 802.3ad Bonding
• Широкие возможности анализа пакетов
• Поддержка IPv6
• Поддержка SIP с функциями Call-ID Persistence

Виртуальный модуль может работать в трех режимах:

• Direct Routing (DR) - режим прямой маршрутизации
• Network Address Translation (NAT) - режим трансляции сетевых адресов
• Source Network Address Translation (SNAT) - режим трансляции исходного сетевого адреса

Более подробно с продуктом от Loadbalancer.org можно ознакомиться в следующих документах:

• Quick start guide
• Quick start guide VA
• Full admin guide
• Enterprise VA Product Sheet
• VMware View 5.0 Guide

Не так давно мы писали про средства управления питанием хост-серверов ESXi, которые имеются в VMware vSphere 5.1. Там мы рассматривали такую политику как Balanced - она разработана для того, чтобы максимально использовать переключения между состояниями P-states процессора в целях экономии энергии. Она обладает слегка большей инерционностью, чем обычное максимальное использование ресурсов процессора (High performance), но почти не влияет на производительность. Эта политика выставлена по умолчанию для серверов VMware ESXi 5.0 и более поздней версии.

Недавно на блоге VROOM! компании VMware появилось интересное исследование, посвященное механизмам управления питанием серверов ESXi. Как и обычно, в качестве инструмента для тестирования и создания нагрузки на хосты ESXi использовался продукт VMware VMmark, который и был разработан для тестирования производительности решений VMware на различных аппаратных платформах.

Сравнивались три подхода к управлению питанием:

• Политика Performance - максимальное использование процессора за счет его поддержки в наивысшем P-state состоянии все время (то есть, по-сути политика энергосбережения отключена). При этом используются только 2 C-state состояния: С0 (running) и C1 (halted). Соответственно, данный режим выдает максимальную производительность, не имеет инерционности и потребляет больше всего энергии. Управляется эта политика BIOS'ом сервера.
• Политика Balanced - сбалансированное энергопотребление за счет переключения между P-states. Эта политика управляется хостом ESXi.
• Политика BIOS Balanced - функции энергосбережения, которые управляются на уровне BIOS сервера (например, Dell Active Power Controller).

Для тестирования производительности использовался стандартный подход VMmark, который предполагает создание возрастающих уровней нагрузки на хост-серверы (Tiles).

С точки зрения аппаратной платформы, использовалась следующая конфигурация:

• 4 сервера Dell PowerEdge R620
• CPUs (на сервер): один Eight-Core Intel® Xeon® E5-2665 @ 2.4 GHz, Hyper-Threading enabled
• Memory (на сервер): 96GB DDR3 ECC @ 1067 MHz
• Host Bus Adapter: два QLogic QLE2562, Dual Port 8Gb Fibre Channel to PCI Express
• Network Controller: один Intel Gigabit Quad Port I350 Adapter
• Версия гипервизора: VMware ESXi 5.1.0
• Дисковый массив: EMC VNX5700
• 62 флеш-диска (SSDs), RAID 0, сгруппированных в 3 x 8 SSD LUNs, 7 x 5 SSD LUNs и 1 x 3 SSD LUN
• Средства управления: VMware vCenter Server 5.1.0
• Версия VMmark: 2.5
• Power Meters: три устройства Yokogawa WT210

Итак, что получилось. График очков VMmark (чем выше столбики - тем лучше). Результаты нормализованы к BIOS Balanced на уровне Tile 1:

Как мы видим, худшие результаты показывает политика BIOS Balanced.

Теперь посмотрим на результаты тестов по новой методике VMmark 2.5, позволяющей измерять производительность сервера на киловатт питания:

Как мы видим, политика Performance показывает самые низкие результаты (это логично, так как энергии потребляется много, а столько мощности не всегда требуется процессору), политика ESXi Balanced показывает результат на 3% лучше, а вот политика BIOS Balanced - аж на 20% лучше.

Кстати, интересны измерения потребления мощности при простаивающем процессоре:

• Политика Performance потребляет 128 Вт
• ESXi Balanced - 85 Вт
• BIOS Balanced - тоже около 85 Вт

Казалось бы, почему тогда не использовать BIOS Balanced? А вот почему - при тестировании нагрузки приложений политика BIOS Balanced выдает огромные задержки (latency), негативно влияющие на производительность:

Таким образом, если снова вернуться к первому графику с обобщенными результатами, можно понять, что политика ESXi Balanced является наиболее оптимальной с точки зрения энергопотребления/производительности, поэтому-то она и установлена по умолчанию.

29 мая компания StarWind, выпускающая решение номер 1 для создания отказоустойчивых хранилищ iSCSI для ВМ VMware vSphere и Microsoft Hyper-V, проводит бесплатный вебинар "The Top-Quality Shared Storage for VMware".

Вебинар пройдет 29 мая, в 16-00 по московскому времени.

На мероприятии, которое проводит опытный инженер StarWind Макс Крафт, вы узнаете о том, как:

• Управлять растущими потребностями в хранилищах и сетевых ресурсах
• Уменьшить расходы на ИТ-инфраструктуру на 50%
• Улучшить эффективность существующей среды виртуализации

Зарегистрироваться.

Не так давно мы писали о том, что VMware планирует создать свое облако на базе VMware vSphere, называемое vCloud Hybrid Service, и сдавать из него виртуальные машины в аренду по модели IaaS. Напомним, что сейчас облачная экосистема компании VMware представляет собой партнерскую модель (см. программу VSPP) распространения услуг IaaS через сеть сервис-провайдеров по всему миру (напомним, что в России этим занимается компания ИТ-ГРАД). Суть этой схемы сводится к тому, что партнеры VMware, использующие ее ПО для предоставления услуг по сдаче в аренду виртуальных машин своим клиентам, платят ей...
Таги: VMware, Hybrid, Cloud, vCloud, VSPP, Cloud Computing

VMware vCenter Server storage filters - фильтры при работе с хранилищами.

Не все администраторы платформы VMware vSphere в курсе, что на сервере VMware vCenter могут быть отключены различные фильтры хранилищ для хостов ESXi, что может оказаться полезным в нестандартных ситуациях.

Эти фильтры могут настраиваться через консоль vCenter в разделе расширенных настроек. Чтобы иметь возможность настраивать фильтры нужно выбрать пункт меню Administration > vCenter Server Settings. Далее в списке настроек нужно выбрать Advanced Settings.

На данный момент актуально четыре фильтра для хранилищ, включенных на хостах ESXi по умолчанию. Они помогают предотвращать ошибки, которые могут привести к повреждению и потере данных в исключительных ситуациях. Однако (зачастую, временно) эти фильтры можно отключить, но делать это нужно обдуманно, при этом не нужно забывать их снова включать.

В таблице ниже представлены назначение фильтров и конфигурация их выключения на сервере vCenter.

Ну и видео для тех, кому удобнее воспринимать из визуального ряда:

Иногда попытка включить фильтр после его временного отключения приводит к ошибке. Тогда нужно на сервере vCenter в файле vpxd.cfg найти и поправить соответствующую строчку в конфигурационном xml-файле:

<filter>
<hostRescanFilter>true</hostRescanFilter>
</filter>

При внесении описанных здесь изменений не обязательно перезапускать сервер vCenter - так как это всего лишь фильтры для мастера добавления хранилищ, они будут применены сразу же. Однако будьте осторожны с изменением фильтров, так как можно потерять данные.

Мы уже писали о компании VMTurbo, выпускающей продукты для мониторинга и управления виртуальной инфраструктурой на базе платформ различных вендоров. На днях VMTurbo сделала бесплатным продукт Virtual Health Monitor, предназначенный для мониторинга гетерогенной инфраструктуры виртуализации.

Надо сказать, что Virtual Health Monitor - это несколько доработанная версия издания Community Edition продукта VMTurbo Operations Manager, являющегося основным коммерческим решением компании, предназначенным для управления виртуальной средой.

 Высокоуровневыми возможностями VMTurbo Virtual Health Monitor являются:

• Возможность отслеживания производительности компонентов виртуального датацентра и определение уровня его работоспособности
• Мониторинг параметров и построение отчетов о виртуальных машинах и хост-серверах в любом количестве (то есть настоящая бесплатность, без ограничений)
• Поддержка нескольких гипервизоров одновременно
• Еженедельный анализ аппаратных мощностей для определения степени эффективности их использования, а также прогнозирование необходимых дополнительных мощностей

Virtual Health Monitor поставляется уже в виде готового виртуального модуля (Virtual Appliance), который можно разместить на следующих платформах (они же, соответственно, и поддерживаются продуктом):

• VMware vSphere
• Microsoft Hyper-V
• RedHat Enterprise Virtualisation (RHEV)
• Citrix XenServer

Virtual Health Monitor был выпущен в преддверии выхода решения VMturbo Operations Manager 4.0, которое будет поддерживать гибридные облака и иметь специальные модули сопряжения с хранилищами различных производителей.

Скачать Virtual Health Monitor можно по этой ссылке.

Не так давно мы писали о том, что компания VMware выпустила обновленную версию руководства по обеспечению безопасности виртуальной инфраструктуры VMware vSphere 5.1 Security Hardening Guide. Также мы писали о VMware Mobile Knowledge Portal (VMKP) - приложении для мобильных устройств, которое позволяет изучать различный контент VMware в целях самообразования (документация, лучшие практики, видеобзоры, обучающие материалы и прочее).

Теперь же вот новость, объединяющая эти две - руководство vSphere 5.1 Hardening Guide стало доступно на VMware Mobile Knowledge Portal:

Кстати, с тех пор, как мы писали о портале VMKP, он сильно изменился к лучшему. Теперь он:

• Доступен для iPad и Android
• Имеет возможность ставить оценки содержимому
• Имеет возможность посылать фидбэк в VMware относительно документов или их частей
• Интегрирован с Facebook and Twitter для тех, кто хочет написать о том, что читает
• Имеет механизм фича-реквестинга

Скачать приложение VMware Mobile Knowledge Portal с содержащимся в нем Security Hardening Guide можно по этим ссылкам: iPad и Android.

В самом конце прошлой недели компания VMware выпустила обновление своей серверной платформы виртуализации - VMware vSphere 5.1 Update 1. Напомним, что версия vSphere 5.1 вышла еще летом прошлого года, поэтому апдейт продукта назрел уже давно.

Из официального списка новых возможностей VMware vSphere 5.1 Update 1:

• Поддержка новых гостевых ОС, приведенных в списке совместимости VMware.
• Исправления ошибок, приведенные здесь.

Надо сказать, что после vSphere 5.1 Update 1, следующие гостевые ОС НЕ будут поддерживаться со стороны VMware (этот релиз пока их поддерживает):

• Windows NT
• Все 16-битные версии Windows и DOS (Windows 98, Windows 95, Windows 3.1)
• Debian 4.0 и 5.0
• Red Hat Enterprise Linux 2.1
• SUSE Linux Enterprise 8
• SUSE Linux Enterprise 9 младше SP4
• SUSE Linux Enterprise 10 младше SP3
• SUSE Linux Enterprise 11 младше SP1
• Ubuntu releases 8.04, 8.10, 9.04, 9.10 и 10.10
• Все релизы Novell Netware
• Все релизы IBM OS/2

Самые интересные исправления ошибок ожидают пользователей в подсистеме работы с хранилищами:

1. Наконец-то при выполнении операции Storage vMotion можно полноценно поменять имя виртуальной машины (то есть, целиком - вместе с виртуальными дисками).

Об этом мы уже писали вот тут. Наконец-то это заработало. На сервере vCenter идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:

provisioning.relocate.enableRename со значением true

2. Увеличенный VMFS Heap Size.

Об этом параметре мы уже писали вот тут:

Он применяется не только к VMFS3, но и VMFS5. Теперь вот что поменялось:

• VMFS Heap может расти до 640 МБ вместо 256 МБ в прошлом релизе. Это позволяет подключать к хосту ESXi совокупный объем хранилищ до 60 ТБ.
  
• Размер кучи выставляется дефолтно 640 МБ для новых установок и сохраняется на уровне уже имеющегося значения для апгрейдов с предыдущих версий.
• Появился новый параметр, позволяющий гарантировать размер кучи - VMFS3.MinHeapSizeMB. Но его нельзя выставить больше, чем 255 МБ (однако она может продолжать расти до 640 МБ).

3. WWNN и WWPN для адаптеров FC HBA отображаются в vSphere Web Client корректно.

Раньше там отображалась бурда в виде ноликов на конце (см. тут). Теперь это поправлено.

Кроме всего этого, появилась хорошая статья KB 2037630, описывающая порядок обновления различных компонентов виртуальной инфраструктуры, построенной на продуктах VMware:

Там же - очень полезная табличка со ссылками:

Скачать VMware vSphere 5.1 Update 1 можно по этой ссылке.

Те из вас, кто пользуется услугами облачного IaaS-хостинга Amazon AWS, наверняка знают, что у этого сервис-провайдера есть решение Storage Gateway, позволяющее организовать гибридную модель хранения данных предприятия, а именно - частично или полностью хранить данные инфраструктуры виртуальных машин VMware vSphere в облачном хранилище Amazon S3.

Теперь же решение Storage Gateway поддерживает не только гипервизор VMware ESXi, но и хранилища платформы Microsoft Hyper-V.

Storage Gateway представляет собой виртуальный модуль (Virtual Appliance), размещенный в виде ВМ на хостах ESXi или Hyper-V, который предоставляет стандартный интерфейс iSCSI и выступает в качестве таргета для хост-серверов с виртуальными машинами (в общем случае поддерживается доступ различных приложений). Работа Storage Gateway возможна в двух режимах:

• Gateway-Cached Volume — в рамках этой архитектуры вы создаете тома для виртуальных хранилищ и монтируете их как iSCSI-устройства для хост-серверов. Виртуальный модуль кэширует данные и сохраняет их в облаке Amazon S3, при этом в инфраструктуре заказчика хранятся только кэшированные данные, которые наиболее часто оказываются востребованными.
• Gateway-Stored Volume — в такой архитектуре все данные виртуальных машин хранятся локально, в рамках инфраструктуры заказчика, а Storage Gateway периодически создает снапшоты (инкрементально) и передает данные отличий от базового образа в облако Amazon S3. Это создает хорошие возможности для сценариев Disaster Recovery.

Storage Gateway передает данные в S3 через защищённый SSL-канал. Более подробно с технической точки зрения о решении можно узнать тут и тут.

С началом поддержки Hyper-V в Storage Gateway компания Amazon вступает в прямую конкуренцию с Microsoft, которая в прошлом году приобрела компанию StorSimple, занимавшуюся тем же самым (только у них это программно-аппаратный комплекс) - предоставлением облачных хранилищ через онпремизные сервисы, размещенные на площадке заказчика (cloud-integrated storage).

Стоимость сервисов Amazon Storage Gateway можно узнать на этой странице.

На страницах vSphere Blog обнаружилась интересная статья Вильяма Лама про патчи, накатываемые на гипервизор VMware ESXi. Приведем здесь основные выдержки, которые могут оказаться полезными при обслуживании виртуальной инфраструктуры VMware vSphere.

Итак, для начала приведем структуру разделов на диске установленной копии ESXi:

Основное отличие от традиционной ОС в VMware ESXi - это то, что все файлы, необходимые гипервизору, хранятся в разделе фиксированного объема (Primary Boot Bank - 250 МБ). Альтернативный Boot Bank такого же размера необходим на случай отката к предыдущей версии ESXi, вне зависимости от того был ли произведен Update (накатывание патчей) или Upgrade (накатывание новой версии ESXi).

Если мы произведем апгрейд ESXi 5.0 на версию 5.1, то структура банков поменяется следующим образом:

Хотя это на самом деле даже и не так - ESXi 5.0 останется в прежнем банке, а загрузчик (Boot Loader) будет указывать уже на альтернативный банк, где разместится ESXi 5.1.

Когда происходит накатывание патча на ESXi - меняется весь банк (основной или альтернативный), поэтому патчи так много весят (по сути обновляется весь основной дистрибутив):

Но в этом есть и преимущество - размер раздела для банка фиксирован и установка ESXi не разрастается со временем при установке новых апдейтов и апгрейдах. Кстати, обратите внимание, что под патчем написано его влияние на систему после установки.

Следующий момент: являются ли патчи кумулятивными, то есть содержат ли они все предыдущие обновления ESXi? Да, все патчи содержат в себе предыдущие, поэтому нет необходимости накатывать их последовательно. Скачать патчи VMware ESXi можно с Patch Portal.

Далее, мы видим, что у патча есть список Bulletin List с суффиксом BG (Bug Fix). Есть также и SG-бюллетени обновлений по безопасности (Security). Оба этих типа бюллетеней могут обновлять как основной банк (base), так и пакеты VMware Tools (драйверы и прочее). Кроме того, в бюллетенях содержатся обновления драйверов устройств для самого сервера ESXi.

SG-бюллетень содержит только обновления подсистемы безопасности, а BG-бюллетени могут содержать новый функционал, исправления ошибок и, опять-таки, обновления, касающиеся безопасности.

Наконец, каждый бюллетень состоит из VIB-пакетов, о структуре которых Вильям хорошо рассказал вот тут. Список установленных VIB-пакетов на хосте ESXi можно узнать командой:

# esxcli software vib list

Будет выведено что-то вроде:

Name              Version                     Vendor Acceptance Level Install Date
----------------- --------------------------- ------ ---------------- ------------
ata-pata-amd      0.3.10-3vmw.500.0.0.469512  VMware VMwareCertified  2012-05-04
ata-pata-atiixp   0.4.6-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-cmd64x   0.2.5-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-hpt3x2n  0.3.4-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04

О том, как накатывать патчи на ESXi из консоли мы уже писали вот тут, также об этом рассказано в KB 2008939.

Как мы уже писали, в третьем квартале 2013 года компания Veeam Software представит новую версию своего решения для резервного копирования и репликации Veeam Backup and Replication 7. Мы уже рассказали о поддержке продуктом Veeam решения для управления облачной инфраструктурой VMware vCloud Director, о плагине для тонкого клиента vSphere Web Client и о восстановлении объектов Microsoft SharePoint.

Но следующая возможность порадует всех тех, кто с нетерпением ждал от Veeam поддержки резервного копирования на ленточные библиотеки, которые все еще остаются весьма распространенным техническим средством в Enterprise-инфраструктурах:

Если некоторые думают, что ленточные приводы для бэкапов уже не используются, то стоит поспрашивать коллег из крупных компаний, таких как РЖД или Газпром. Ленты живут и будут там жить еще долго, в том числе и потому, что они позволяют хранить резервные копии в географически удаленном от основного датацентра месте (на случай катастрофы).

Veeam Backup and Replication 7 будет поддерживать виртуальные ленточные библитеки (virtual tape library, VTL), физические ленточные библиотеки (tape libraries) и отдельные приводы (standalone drives).

Возможность Backup to tape позволяет осуществлять резервное копирование виртуальных машин на ленточные приводы (в рамках одной или нескольких задач), а также позволяет архивировать весь репозиторий Veeam Backup and Replication 7 на ленты.

Кроме этого, новая версия Veeam Backup and Replication 7 имеет возможность Files to tape, которая позволяет производить резервное копирование отдельных файлов ОС Windows или Linux на ленты. Важно, что для этой возможности поддерживаются не только виртуальные, но и физические серверы. При этом такой тип резервного копирования поддерживает механизм Microsoft VSS для создания консистентных бэкапов.

Интересно, что бесплатный продукт Veeam Backup Free Edition будет поддерживать возможность Files to tape, а также восстановление файлов, резервные копии которых сделаны с помощью встроенного средства Windows NTBackup.

Функция Restoring backups from tape позволяет восстановить с ленточных носителей резервные копии виртуальных машин на один из репозиториев Veeam, после чего станут доступны к использованию возможности Instant VM Recovery, Veeam Explorer for Microsoft Exchange и все другие Enterprise-фичи Veeam.

Помимо восстановления виртуальных машин целиком, есть, конечно же, и восстановление отдельных файлов с лент - Restoring files from tape. Выбираете целевую папку на физической или виртуальной машине и восстанавливаете туда необходимые файлы с ленточных приводов. Вот так, дождались - и это хорошо. Скоро не будет необходимости использовать Veeam для резервного копирования ВМ на дисковые устройства, а затем сторонний софт для сброса резервных копий на ленточные приводы. Теперь можно будет обходиться только решением Veeam Backup and Replication 7.

Кроме того, мы не упоминали о еще одной возможности Veeam Backup and Replication 7 - Virtual Lab for Hyper-V. Напомним, что еще в версии Veeam Backup and Relication 6.1 появилась поддержка технологии vPower для инфраструктуры резервного копирования виртуальных машин на платформе Hyper-V. Это касается и техники Instant VM Recovery - мгновенного восстановления ВМ за счет ее запуска напрямую из резервной копии.

Теперь же для инфраструктуры Hyper-V появилась поддержка виртуальных лабораторий по запросу (On-Demand Sandbox), которые для VMware vSphere были доступны еще в пятой версии продукта.

С помощью техник мгновенного запуска резервных копий администратор может запустить набор приложений в виртуальных машинах, являющихся изолированными копиями машин производственной среды, и проводить там какие угодно тесты. Для тестовой лаборатории задается хост Hyper-V, где это будет происходить, Datastore, Proxy Appliance для доступа Veeam Backup к тестовой лаборатории с виртуальными машинами в изолированной сети и настройки этой самой сети.

Более детально о возможности Virtual Lab for Hyper-V можно почитать вот в этом посте.

Не так давно мы писали о том, что компания VMware выпустила черновик своего регулярно обновляемого руководства по обеспечению безопасности VMware vSphere 5.1 Security Hardening Guide. На днях, после двухмесячных публичных обсуждений, вышла окончательная версия документа vSphere 5.1 Security Hardening Guide с примечаниями и правками от комьюнити.

На различных вкладках документа Excel можно найти сведения о защите следующих компонентов инфраструктуры vSphere:

• Виртуальные машины
• Хосты ESXi
• Виртуальные сети
• Сервер управления vCenter Server и его БД.
• Сервер vCenter Web Client
• Сервер единой аутентификации vCenter SSO
• Виртуальный модуль vCenter Virtual Appliance (VCSA), правда всего 3 пункта
• Средство обновления vCenter Update Manager

В отличие от предыдущих версий документа, категорий стало несколько больше, а пункты в них стали как-то поконкретнее. Также отметим, что теперь появилась централизованная страничка, где будут собраны все Hardening Guides (почему-то там нет руководства по VMware View):

http://vmware.com/go/securityguides

Традиционно к руководящим инструкциям по обеспечению безопасности и защите виртуальной среды VMware vSphere прилагается лог изменений документа.

Не так давно мы уже писали о накладных расходах на виртуализацию по памяти для виртуальных машин на платформе VMware vSphere, а сегодня поговорим о виртуальных ПК, которые предъявляют дополнительные требования к объему памяти сверх выделенного на обеспечение работы различных графических режимов в гостевой ОС.

Для начала отметим, что на платформе VMware Horizon View 5.2 появились следующие изменения по сравнению с предыдущими версиями в плане графических режимов виртуальных ПК:

• Horizon View 5.2 не позволяет установить 24-битную цветовую палитру, теперь используется только 32-битная.
• Horizon View 5.2 позволяет устанавливать разрешения только 1680×1050, 1920×1200 и 2560×1600. Дефолтным является 1920×1200.

Теперь о накладных расходах по памяти для виртуальных машин.

3D Software Rendering отключен

В этом случае расходы дополнительной памяти сервера на виртуальный ПК зависят от используемого разрешения и количества мониторов для виртуальной машины (значения приведены в мегабайтах):

Как вы знаете, в ESXi 5.0 появились возможности VMX Swap, которые позволяют создать swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте. Он в разы уменьшает использование физической памяти на Overhead виртуальных машин в случае недостатка ресурсов.

Затраты хранилищ (в мегабайтах) на создание второго *.vswp файла для механизма VMX Swap рассчитываются следующим образом:

Как мы видим, для некоторых виртуальных ПК может потребоваться более полугигабайта дополнительного дискового пространства.

3D Software Rendering включен

Для виртуальных ПК отдельно или в пределах пула можно установить объем видеопамяти (VRAM, не путать с vRAM) доступный гостевой системе, что влияет на накладные расходы на виртуализацию.

В этом случае дополнительно требуемая физическая память будет рассчитываться как 64 МБ + 16 дополнительных МБ на каждый монитор.

Что касается SWAP-файла, то требуемый для него объем существенно выше, чем в первом случае. Он зависит от выделенной видеопамяти:

То есть, в некоторых случаях дополнительные затраты на хранилище отдельной виртуальной машины могут достигать 2 ГБ. Чтобы это все учитывать при планировании инфраструктуры виртуальных ПК, можно воспользоваться калькулятором от Andre Leibovici, по материалам которого и написана эта заметка.

С удовольствием представляем вам очередного спонсора VM Guru - компанию Rentacloud, предоставляющую виртуальные машины в аренду и другие облачные сервисы на платформах VMware vSphere и Microsoft Hyper-V.

Компания Rentacloud - это поставщик и интегратор облачных услуг, осуществляющий комплексный подход к предоставлению и интеграции облачных сервисов public и private cloud. В предоставлении облачных услуг специалисты компании особенно фокусируются на безопасности, масштабируемости и простоте использования технологий. У Rentacloud размещают инфраструктуру такие клиенты как Московский ювелирный завод, ЗАО 1С, Рарус и другие.

Инфраструктура, предоставляющая сервисы виртуальных машин в аренду имеет следующие компоненты:

• Платформа VMware vSphere 5.1
• Платформа Microsoft Windows Server 2012 Hyper-V
• Сетевое оборудование Juniper Networks
• Серверы Dell и HP
• Системы хранения данных NetApp
• ЦОДы в Москве и Амстердаме

У компании простые и понятные ценники на виртуальные машины VMware и Microsoft:

Ключевые преимущества услуг компании Rentacloud:

• 24/7 Support - круглосуточная поддержка 365 дней в году.
• Бесплатный тест 7 дней - все облачные решения можно тестировать неделю бесплатно.
• Отказоустойчивость - предоставление высокого уровня доступности в соответствии с SLA 99,95%.

Более подробно об облачных услугах компании Rentacloud и аренде виртуальных машин можно узнать по этой ссылке.

Недавно мы писали про сетевой траблшутинг хостов VMware ESXi, где упоминали утилиту vmkping, с помощью которой можно пинговать какой-нибудь IP-адрес через  порт VMkernel. Но как быть если у вас 2 таких порта?

Через какой адаптер пойдет пинг?

Для этого случая есть параметр -I, который определяет через какой интерфейс пинговать (в нашем случае vmk1, а не vmk2):

# vmkping -I vmk1 IP-target

Источник, который рекомендует еще вот эту статью про vmkping с Jumbo Frames.

Время от времени мы пишем о графических материалах, позволяющих пользователям и партнерам VMware документировать виртуальную инфраструктуру VMware vSphere, VMware View, VMware SRM и прочее. Мы писали о наборе картинок для VMware vSphere 5 тут и тут, вот об этом наборе иконок, картинок и диаграмм, об этом, а также и об этом неофициальном наборе стенсилов Visio.

Последний как раз вчера и обновился в составе третьей части, которая теперь включает в себя картинки, графику и стенсилы для следующих компонентов:

• Orchestrator
• CapacityIQ
• Chargeback
• Appspeed
• Site Recovery Manager
• Studio
• vCloud Director
• VMware Server
• View
• ThinApp
• vCloud Director

Превьюшки некоторых наборов:

Скачать все это дело можно по следующим ссылкам:

Сделал этот полезный набор Maish Saidel-Keesing.

А вот актуальные на сегодняшний день официальные иконки, картинки и диаграммы от VMware Branding Team:

• VMware-Stencil2-vSphere.zip (16.7 MB)
• VMware-Stencil1-vSphere.zip (16.3 MB)

В формате Power Point:

• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_2_of_3.pptx  (2.6 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_3_of_3.pptx  (2.9 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_1_of_3.pptx  (17.4 MB)

Обратите внимание, что VMware настаивает на включении в документы, которые содержат эти картинки, какого-то бредового текста, который вы увидите в начале данных презентаций.

Еще парочка интересных наборов:

• VMware View Visio Stencil Download (и в .VSX XML)
• VMware Icons Visio Stencil Shapes

Иконки там вот такие:

Есть еще вот такой набор картинок и стенсилов (некоторые уже устарели, некоторые еще в бою):

• VMware_VMGuru_stencil_v2.0

И вот такой:

• VMware Visio stencil pack 

Если в инфраструктуре есть продукты Veeam:

• Veeam Stencils for VMware and Hyper-V

Вроде все. Не благодарите.

На днях компания VMware выпустила полезную штуку под названием vCenter Certificate Automation Tool 1.0. Как знают многие администраторы VMware vSphere в последней версии платформы (5.1) сертификаты стали играть более заметную роль, чем ранее, и теперь их приходится настраивать для различных компонентов.

Теперь же с помощью утилиты командной строки vCenter Certificate Automation Tool 1.0 (это набор скриптов) можно просто заменить сертификаты для следующих продуктов VMware:

• vCenter Server
• vCenter Single Sign On
• vCenter Inventory Service
• vSphere Web Client
• vCenter Log Browser
• vCenter Orchestrator (VCO)
• vSphere Update Manager (VUM)

Утилита работает в интерактивном режиме, и прежде, чем приступить к работе с ней, необходимо ознакомиться с инструкциями, приведенными в KB 2041600. Также полезно будет почитать KB 2044696 (это о том, как сгенерировать сертификаты для использования с vCenter Certificate Automation Tool).

Надо отметить, что продукт поддерживает только vCenter 5.1 и его компоненты, развернутые на платформах Windows Server 2003 R2 SP2 и Windows Server 2008 R2 SP2.

Для vCenter Certificate Automation Tool есть три режима работы:

• Single virtual machine (all services in one machine) - в этом случае все сервисы SSL Certificate Automation Tool развертываются в одной виртуальной машине.
• Multiple virtual machines (machine per service) - каждый сервис устанавливается на отдельной виртуальной машине для выполнения функций по замене сертификатов для одного из 7 продуктов (они приведены выше).
• Mixed mode (multiple services per machine) - в этом случае несколько сервисов утилиты развертываются на одной машине (где надо заменять сертификаты), а некоторые сервисы - на других.

Кроме того, напомним для интересующихся, что в данный момент разрабатывается средство vCert Manager от VSS Labs, выполняющее схожие функции (но намного больше), бета которого уже есть:

Вот какие функции по сравнению с vCenter Certificate Automation Tool заявляют авторы:

Более подробно об утилите vCert Manager можно прочитать по этой ссылке.

На днях компания Veeam Software объявила о выпуске обновленной версии продукта для мониторинга и решения проблем в виртуальной инфраструктуре Veeam Management Pack for System Center Operations Manager 6.0.

Напомним, что о возможностях версии Management Pack for System Center Operations Manager 5.6 мы рассказывали вот в этой заметке.

Что нового появилось в версии Veeam MP for System Center 6.0 (помимо того, что убрали слово nworks, доставшееся от купленной компании, разрабатывавшей этот продукт когда-то):

• Поддержка операционной системы Microsoft Windows Server 2012
• Поддержка средств управления инфраструктурой Microsoft System Center 2012 SP1
• Полная поддержка платформы виртуализации VMware vSphere 5.1
• Новые представления Topology View для хранилищ, сети и вычислительных ресурсов
• 30 новых представлений (Dashboards) для System Center 2012
• Новые отчеты по аналитик VMware vSphere
• Улучшенный механизм анализа производительности инфраструктуры и средства анализа корреляции событий

Полный список нововведений Veeam Management Pack for System Center Operations Manager 6.0 приведен в документе "What’s New in v6". Более подробно узнать о продукте и скачать пробную версию можно по этой ссылке.

В инфраструктуре VMware vSphere для диагностики сетевых неполадок иногда приходится в сервисной консоли серверов VMware ESXi тестировать различные соединения. В этой заметке мы вкратце опишем, как это делается.

Прежде всего, обычный пинг через стандартный Management-интерфейс:

# ping <IP хоста>

Пинг через порт VMkernel (в ESXi это тот же самый интерфейс, а в ESX - другой):

# vmkping 192.168.48.133

PING 192.168.48.133 (192.168.48.133): 56 data bytes
64 bytes from 192.168.48.133: icmp_seq=0 ttl=64 time=0.978 ms
64 bytes from 192.168.48.133: icmp_seq=1 ttl=64 time=1.009 ms

Для проверки соединения сервера VMware ESXi с хостом по какому-нибудь порту используется утилита netcat (nc). Telnet есть только на ESX. Формат использования netcat:

# nc -z <IP хоста> <порт хоста>

Например:

# nc -z 192.168.48.133 80
Connection to 192.168.48.133 80 port [tcp/http] succeeded!

С помощью netcat можно проверять только TCP-соединения, для UDP (флаг -uz) всегда будет статус succeeded (даже если порт заблокирован или закрыт), так как соединения по UDP не устанавливается. Для того, чтобы тестировать UDP-соединения можно воспользоваться утилитой tcpdump-uw.

Команда nc может быть использована для сканирования диапазона портов (будьте осторожны со сканированием, чтобы не навлечь гнев безопасников):

# nc -w 1 -z 192.168.48.133 20-81
Connection to 192.168.48.133 22 port [tcp/ssh] succeeded!
...
Connection to 192.168.48.133 80 port [tcp/http] succeeded!

Опция -w определяет таймаут между соединениями.

Для траблшутинга SSL-соединений может быть использована следующая команда:

# openssl s_client -connect <IP хоста>:<ssl-порт>

В результате, вы увидите нечно подобное:

# openssl s_client -connect 192.168.48.133:443
CONNECTED(00000003)

Вывод может содержать полезную информацию об SSL-сертификатах, что может помочь в дальнейшем при поиске источника проблемы.

Для того, чтобы вывести список TCP/UDP-соединений на хосте, можно воспользоваться командами:

• На ESX 3.5/4.x – # netstat -tnp
• На ESXi 4.1 – # esxcli network connection list
• На ESXi 5.0 – # esxcli network ip connection list

Выводом будет что-то вроде:

# esxcli network connection list
Proto  Recv-Q  Send-Q    Local Address       Foreign Address     State        World ID
  tcp    0       52      192.168.48.136:22   192.168.48.1:55169  ESTABLISHED  0
  tcp    0       0       127.0.0.1:62024     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:57867     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:62196     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:8307      127.0.0.1:52943     ESTABLISHED  5790
  tcp    0       0       127.0.0.1:52943     127.0.0.1:8307      ESTABLISHED  5790
  tcp    0       0       127.0.0.1:80        127.0.0.1:55629     ESTABLISHED  5785
  tcp    0       0       127.0.0.1:55629     127.0.0.1:80        ESTABLISHED  6613
  tcp    0       0       127.0.0.1:8307      127.0.0.1:56319     ESTABLISHED  5785
  tcp    0       0       127.0.0.1:56319     127.0.0.1:8307      ESTABLISHED  5785

Как мы уже писали, скоро компания Veeam Software представит новую версию своего решения для резервного копирования и репликации Veeam Backup and Replication 7. Постепенно Veeam будет раскрывать новые функции продукта, который будет выпущен в третьем квартале 2013 года. Сначала мы рассказали о поддержке продуктом Veeam решения для управления облачной инфраструктурой VMware vCloud Director, а затем о плагине для тонкого клиента vSphere Web Client.

Теперь настал черед третьей функции - Veeam Explorer for Microsoft SharePoint.

Напомним, что у Veeam уже есть решения Veeam Explorer for Exchange (восстановление писем, почтовых ящиков и прочих объектов почтового сервера), а также средства U-AIR (Universal Application-Item Recovery) для восстановления объектов баз данных Microsoft SQL Server. Теперь вот можно будет восстанавливать и документы SharePoint:

Возможности Veeam Explorer for Microsoft SharePoint (все они не требуют установки агентов в ВМ):

• Просмотр базы данных SharePoint прямо в сжатой и дедуплицированной резервной копии, без необходимости ее восстановления.
• Поиск отдельных документов SharePoint.
• Восстановление объектов на оригинальный сервер SharePoint, а также возможность их отсылки вложением по email отдельным пользователям.
• Поддержка ВМ с SharePoint как на платформе Microsoft Hyper-V, так и на VMware vSphere.

Продукт Veeam Backup and Replication 7 будет выпущен в третьем квартале 2013 года.

Как многие из вас знают, в VMware vSphere 5.1 была введена возможность обновления пакета VMware Tools "без перезагрузки" гостевой ОС. Многие пользователи были удивлены - как же так, после обновления драйверов не нужно перезагружать сервер? На самом деле это небольшой маркетинговый обман - перезагружать ОС в некоторых случаях, все-таки, придется - чудес не бывает.

Просто исторически (до vSphere 5.1) обновление VMware Tools в любом из компонентов этого пакета требовало перезагрузки. При этом для Windows-систем ее можно было отложить используя опции установщика, например, такие (или так):

setup.exe /S /v"/qn REBOOT=R"

или

setup.exe /S /v"/qn REBOOTPROMPT=S"

Для ОС Unix/Linux драйверы и модули ядра отправлялись на стейджинг и активировались в системе после перезагрузки сервера.

Теперь же, в vSphere 5.1 обновление не всех компонентов VMware Tools требует перезагрузки, однако это применимо только к ОС Windows, для Linux все осталось по-прежнему. Перезагрузка требуется при обновлении следующих компонентов, входящих в состав пакета VMware Tools:

• Драйвер видеоадаптера VMware SVGA II. Он используется для ОС младше Windows Vista, однако может использоваться в некоторых случаях и для других ОС. Если в системе установлен драйвер VMware SVGA 3D, то его обновление, скорее всего, не потребует перезагрузки. Однако в KB 2015163 указано, что перезагрузка произойти, все-таки, может.
• Драйвер VMware Pointing Device Driver (PS/2). Этот драйвер используется по умолчанию для всех версий Windows, но обновляется крайне редко. В VMware vSphere 5.1 появился VMware USB Pointing Device driver, который не требует перезагрузки. Если это критично - можно использовать его.
• Драйверы VMware VMSCSI Controller и VMware PVSCSI Controller Driver. Обновление этих драйверов, скорее всего, потребует перезагрузки, но только в случае, если один из этих драйверов используется для системного диска (с папкой C:\Windows), либо для устройства, файловая система которого используется на момент установки. В других случаях (например, у вас нет дисков на контроллере PVSCSI) - перезагрузка не требуется.
• Опциональные компоненты. К ним относятся HGFS (функции shared folders) и ThinPrint, которые могут потребовать перезагрузки.

Какие особенности есть у процесса обновления VMware Tools без перезагрузки в VMware vSphere:

• Работает это для Windows Vista и выше.
• Работает только для ОС Windows.
• Для виртуальной машины требуется Virtual Hardware 9 или более поздней версии.

Также стоит прочитать статью о том, следует ли обновлять VMware Tools при апгрейде хостов VMware vSphere.

Многие из вас, кто использует кластеризацию MSCS в виртуальных машинах на платформе VMware vSphere, возможно, замечали, что когда используется кластер Across Boxes (т.е. между ВМ на разных хостах), то перезагрузка хоста VMware ESXi занимает весьма продолжительное время (иногда - до получаса).

При этом на экране консоли написано:

Loading module multiextent.

В логе VMkernel можно увидеть следующее:

Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.828 cpu0:4096)WARNING: ScsiCore: 1353:Power-on Reset occurred on naa.6006016045502500176a24d34fbbdf11
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.830 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:3:0 (naa.6006016045502500166a24d34fbbdf11)
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:02:37.842 cpu3:4099)ScsiDeviceIO: 1672:Command 0x1a to device "naa.6006016045502500176a24d34fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0

Дело здесь в том, что поскольку узлы кластера виртуальных машин используют диск RDM, который напрямую пробрасывается в виртуальную машину и для него используются SCSI reservations, то хост ESXi тратит много времени на обнаружение параметров устройства.

Избежать этого очень просто. Для этого:

• В ESX / ESXi 4.0 нужно выставить минимальное значение на число повторов операций при обнаружении конфликтов SCSI-резерваций (в Advanced Settings хостов):

Scsi.UWConflictRetries = 80

• Для ESXi 4.1 появилась дополнительная опция, которая уменьшает таймаут при загрузке в случае обнаружения конфликта. Это значение необходимо выставить в:

Scsi.CRTimeoutDuringBoot = 1

• Начиная с ESXi 5.0, опция Scsi.CRTimeoutDuringBoot больше не действует. Теперь нужно использовать команды множества esxcli storage. Для этого:

Сначала надо найти NAA-идентификатор устройства (физического LUN, на котором используется RDM). Для этого нужно зайти в управление путями до устройства (Manage Paths) и посмотреть на строчку, начинающуюся с naa...... - это и есть naa id.

Далее в консоли сервера ESXi нужно выполнить следующую команду (она пометит LUN как изначально зарезервированный):

esxcli storage core device setconfig -d naa.id --perennially-reserved=true

После этого хост ESXi, где были проведены данные манипуляции, будет загружаться быстро.

Более подробно о данной проблеме рассказано в KB 1016106.

За что я всегда любил VMware, так это за то, что она, в отличие от Microsoft и Citrix, никогда не выпускала фича-паки, сервис-паки, мега-паки, а ограничивалась обычными Update 1,2,3 и т.п. для платформы виртуализации VMware vSphere. Однако, это время, похоже, прошло - VMware выпустила Horizon View 5.2 Feature Pack 1.

Напомним, что недавно была выпущена обновленная версия продукта для виртуализации настольных ПК VMware Horizon View 5.2, которая является частью VMware View Horizon Suite. Внимательные пользователи при развертывании пулов виртуальных ПК могли заметить следующую приписку к функциональности HTML access (доступ к консоли через браузер посредством HTML5):

Соответственно, данная функциональность до настоящего времени была недоступна.

Как можно увидеть из первой картинки, пакет VMware Horizon View 5.2 Feature Pack 1 содержит 2 нововведения:

• Доступ к виртуальным ПК через браузер (HTML Access) - теперь уже стандартная функциональность Horizon View по доступу к виртуальным ПК через веб-браузер посредством HTML5, которая раньше называлась AppBlast. Для работы этой возможности необходимо поставить специального агента (HTML Access Agent) на виртуальные ПК, к которым требуется доступ через веб-браузер (около 6 МБ), а также HTML Access Web Portal на сервер View Connection.
• Unity Touch - возможность получения доступа к приложениям виртуального ПК с планшета в "мобильном" стиле. Для этого на ПК тоже требуется поставить специального агента - Remote Experience Agent.

Остановимся на Unity Touch поподробнее. Эта штука позволяет вывести менюшку с приложениями рабочего стола Windows на вашем iPad, без необходимости идти в меню "Пуск" или еще куда и свободно переключаться между ними с помощью бокового меню. Можно переключаться между запущенными приложениями (а также удобно "убивать" их) и своими документами:

В этом всем множестве организован поиск, что весьма удобно.

Работает эта штука с обновленными клиентами VMware View, доступными на iOS App Store (под iPad и iPhone), Google Play Store, а также Amazon AppStore for Android. Кроме того, полный их список, как всегда, можно найти здесь.

Кстати, возможности VMware Unity Touch выросли из проекта AppShift, демо которого было показано на VMworld 2012:

Более подробно процедура установки и настройки фича-пака приведена в документе "VMware Horizon View Feature Pack Installation and Administration".

Мы уже писали о том, что в скором времени увидит свет новая версия ПО для резервного копирования виртуальных машин - Veeam Backup and Replication 7. Сначала было объявлено о поддержке новой версией решения vCloud Director, теперь же компания Veeam показала плагин для тонкого клиента vSphere Web Client.

Те, кто хочет узнать о плагине Veeam для vSphere Web Client, могут зарегистрироваться на вебинар, который пройдет 26 марта.

Этот шаг Veeam видится вполне логичным на фоне того, что компания VMware полностью переходит на управление виртуальной инфраструктурой через веб-клиент в следующей версии платформы виртуализации VMware vSphere 6.

Продукт Veeam Backup and Replication 7 будет выпущен в третьем квартале 2013 года.